\section*{Могучая кучка}
Собственно, из трёх программ, prman, shader и
   txmake, состоит вычислительное ядро Renderman Pro Server. Как мы
   уже говорили раньше, подавляющее большинство Renderman-совместимых
   рендереров придерживается такой же архитектуры, просто называя
   файлы другими именами. Приведём лишь некоторые из них:
 
%\begin{tabular}{ l c c c r }
\begin{tabular}{ | c | c | c | c | c | }
\hline
\textbf{Продукт} & \textbf{Рендерер} & \textbf{Компилятор} & \textbf{Готовый} & \textbf{Обработчик}\\
  &   & \textbf{шейдеров} & \textbf{шейдер} & \textbf{текстур}\\
\hline
Prman & prman & shader & *.slo & txmake \\
\hline
AIR & air & shaded & *.slb & mktex \\
\hline
RenderDotC & renderdc & shaderdc & *.dll & texdc \\
\hline
3delight & renderdl & shaderdl & *.sdl & tdlmake \\
\hline
Aqsis & aqsis & aqsl & *.slx & teqser \\
\hline
\end{tabular}   
 

Ссылку на постоянно обновляющийся список рендереров
   вы найдёте в конце главы, но уверяю вас – у участников списка всё
   обстоит аналогичным образом.
 

Для
   любознательных: вы наверняка знаете,
   что в комплекте поставки Maya есть
   программа под названием {\it render.}exe, которая
   позволяет рендерить майские сцены из командной строки?Я не буду
   проводить аналогии – хотя бы потому, что остальных программ из
   нашей троицы у Maya нет в силу
   особенностей архитектуры.
 

А у нас настало время систематизировать наши знания
   о внутренностях Renderman-совместимого рендерера. Проще всего будет
   это сделать в виде схемы, показывающей путь данных внутри
   системы:
 

\gr{image059}
 

Как видите, мы умудрились ужать несколько десятков
   страниц убористого технического текста в одну простую
   диаграмму.
 

Каким же образом в этот процесс встраивается MTOR?
   Добавим в схему недостающие элементы (а заодно уберём из неё
   временные файлы *.TX и *.SLO):
 

\gr{image061}
 

Как видно из обновлённой диаграммы, майская сцена
   обрабатывается МТОRом и превращается в файлы геометрии *.RIB;
   материалы, разработанные в SLIM, конвертируются в шейдеры *.SL. С
   текстурами чуть сложнее, но ненамного – вызовы их обработчиков
   также настраиваются в SLIM.
 

{\it Замечание:} Для большей простоты
   понимания мы не указали в этой схеме Alfred.
 

А как же та самая пресловутая совместимость между
   рендерерами в рамках стандарта, о которой так громко говорили
   большевики всю эту главу? Нет ничего проще: берём страничку
   соответствия файлов между различными рендерерами и делаем в схеме
   соответствующую замену. На практике, полностью взаимозаменимых
   рендереров не бывает (как бы их авторы не старались), но
   спецификация стандарта даёт нам уверенность в том, что особых
   дополнительных усилий такая замена не потребует.
 

А теперь представьте себе, что между любыми
   элементами этой новой диаграммы можно встроить другие программы и
   скрипты на различных языках программирования, которые будут
   преобразовывать ваши данные.
 

Вы считаете, что и этого мало? Ну тогда давайте
   вернёмся к нашей схеме и описанию нашей триады и дополним её
   некоторыми немаловажными деталями, которые мы не затронули в первом
   заходе.
 
    Утилита txmake принимает на входе файлы формата
     TIFF. На самом деле, список поддерживаемых форматов гораздо длинее,
     и включает в себя: Maya IFF, SGI, SUN, TGA, Alias, GIF, JPEG, LBM,
     BMP, ICO, форматы систем X11 (например, майские иконки в файлах
     XPM), PhotoCD, 24битные raw bitmaps и некоторые другие, а начиная с
     версии 12 – становящийся де-факто стандартом индустрии
     OpenEXR.

    В поставке Renderman Pro Server есть утилита
     sho.exe, которая позволяет конвертировать между всеми этими
     форматами.

     Кстати говоря, в поставке Maya есть утилита imgcvt.exe, которая
     делает почти то же самое – конвертирует между форматами.
     Преимущество sho в том, что она может ещё и показывать файлы на
     экране.

     Признайтесь честно – когда вы в последний раз заглядывали внутрь
     Maya/bin?

    Язык шейдеров SL можно расширить за счёт своих
     собственных процедур. Сделать это можно, написав свою собственную
     DLL (в нашем случае называемую на юниксоидный лад: DSO). Поверьте
     мне – это не так сложно, как кажется, и для этого совсем не
     обязательно знать язык C или C++ - я с успехом писал DSO на
     Паскале. Классические примеры расширения SL – frankenrender (вызов
     одного рендерера из шейдера, исполняемого в другом рендерере;
     именно так в стародавние времена в prman встраивали raytracing –
     просто вызывали BMRT) и Vtexture (использование векторных файлов в
     качестве текстур).

    Вы уже знаете, что формат RIB можно генерировать
     своими собственными программами; это очевидно, поскольку формат это
     простой и в основной своей ипостаси – текстовый. О чём мы в нашей
     главе не говорили – так это о том, что этот формат также можно
     расширять при помощи динамических генераторов RIB-кода, вызовы
     которых встраиваются непосредственно в сами RIBы. Такие генераторы
     можно писать как в виде DLL/DSO, так и непосредственно как
     исполняемые файлы, или даже скрипты на Perl.

     {\it Комментарий в сторону:} Я уже говорил, что Perl -
     язык истинных криптоманьяков. Хорошим подтверждением этой гипотезе
     является тот факт, что базовым скриптовым языком в ILM и Google
     избран Python.

    Начиная с версии 11.5, prman позволяет встраивать
     ваши собственные фильтры внутрь рендерера для более глубокого
     процессинга RIB. Опять таки, эти фильтры представляют из себя
     DLL/DSO с определённой схемой вызовов. Начиная с версии 12.0, эти
     фильтры описаны в документации.

    prman может рендерить во множество файловых
     форматов: TIFF, Maya IFF, Softimage, TGA, SGI, CIN, PIC, Alias. Но
     этот список можно легко увеличить при помощи своих собственных
     плагинов, в этом случае называемых display drivers. Экспериментируя
     с prman в нашей главе, мы рендерили сразу в окно просмотра; такая
     возможность реализуется при помощи плагина d\_windows.dll. Пробуя на
     зуб MTOR, мы считали картинку непосредственно в окно программы it –
     делается это при помощи драйвера d\_socket. Разрабатывая ShaderMan
     (о нём поговорим чуть попозже, но уже совсем скоро), я поставил
     перед собой задачу рендерить напрямую в окно своей программы – и
     решил эту задачу, написав специальный display driver. Стандартная
     для prman 12 возможность считать в файлы формата OpenEXR может быть
     реализована и в более старых версиях рендерера – при помощи таких
     же драйверов (их можно скачать с сайта OpenEXR или найти
     через Google). Хотите
     считать в PNG, JPEG2000 или свой собственный über-формат? Просто
     напишите драйвер.

Почему множество людей, FX-домов и студий во всём
   мире используют Renderman Pro Server? Сведём всё предшествующее
   описание, все эти десятки страниц, картинок и схем в один
   список:

\begin{itemize} 
    \item Стандарт Renderman
    \item Скорость работы
    \item Соответствие тем нормам, которые мы определили как необходимые для продакшн рендерера
    \item Удобство и простота в освоении
    \item Расширяемость
\end{itemize}

Добавим в эту гремучую смесь такие свойства
   рендерера, как:

\begin{itemize} 
    \item быстрый motion blur – почти не влияющий на скорость рендеринга (сравните с другими)
    \item настоящий высококачественный displacement
    \item SL – который сам стоит целого списка
\end{itemize}
и вы получите тот динамит, который взорвал индустрию спецэффектов. Технологию с великим прошлым, динамичным настоящим и полным оптимизма
будущим.